feat: Run reactive effects - #2508

Reimplements the concurrency model from #2182 so that a flush starts
effects and never waits for their async parts:

- Remove the global reactive lock from the session loop, invalidate_later
  and ExtendedTask completion. The receive loop never awaits a flush.
- Invalidations call request_flush(), which schedules one coalesced flush
  on the next loop pass with a fresh contextvars context.
- The internal flush starts each pending context as a task (priority
  orders starts only), keeps strong references to those tasks, and, like
  R's flushReact(), doesn't start a second flush while one is active.
- Input updates and invalidate_later invalidations are sync cycle-start
  actions, run only from the session's own output flush: idle -> send
  outputs -> start the next action. Dispatch messages run as tasks.
- AppSession._flush sends once per cycle (held while the session is
  busy), always including the empty message the client needs to settle
  output progress, and copies+resets the queues before awaiting the send.
- Exceptions escaping an effect task are reported to its session.
- Public reactive.flush() waits until settled, but returns right away when
  called from within a flush or when nothing is pending or running.

Co-authored-by: Josh Taillon <joshua.taillon@posit.co>

Effects now run concurrently, so a streamed message can land after one appended later (posit-dev/shinychat#417). Check each message is present; TODO restore the order check once that issue is fixed.

A 3s async effect in one tab must not stop the other tab's timer. Fails on main (the global lock freezes the other tab).

With the flush reentrancy guard, the stream's task starts before later effects append, so the ordered assertion holds again.

- Track "inside a flush or effect run" by task identity (a ContextVar
  holding the owning task), not an inherited bool. Tasks an effect starts
  (ExtendedTask bodies, chat tool calls, background loops) now wait for
  dependents instead of returning at once, and don't wait on the effect
  that started them.
- Add flush_pass(): run, or wait for, one complete flush that starts after
  the call. reactive.flush() always does at least one pass and no longer
  spins re-running flushes while one is active.
- ExtendedTask waits for a full flush pass before starting a queued
  invocation, so dependents see every result.
- Rewrite the reactive.lock() docstring: nothing takes it any more.

Fill in the App._sessions_needing_flush placeholder (R's
appsNeedingFlush). A session asks for a flush when it has something to
send: the idle transition, a queued cycle action, send_input_message(),
on_flush() registration, and a finished message handler. After each
reactive flush the app flushes just those sessions, and an error in one
closes that session instead of skipping the rest.

- Message handlers run in session-owned tasks that reactive.flush()
  doesn't wait on, so handlers that await reactive.flush() can't deadlock.
- Requests made by a session's own flush callbacks don't schedule another
  flush (their messages go out in the one being sent), avoiding a loop.
- Only downloads take the busy count; an upload or dynamic route no
  longer pauses the session's cycle.
- `_flush` skips straight to a queued action only when there is one.

Covers every case from the review's repro scripts, plus edge cases:
async calc sharing (incl. invalidated mid-run and shared errors), effect
runs not overlapping, reactive.flush() from effects, tasks, flush
callbacks and message handlers, ExtendedTask queued results, per-session
flush requests and error isolation, one message per cycle (even empty),
timers waiting while busy, busy only for downloads, and session teardown.
The timer test uses a longer interval so it no longer flakes under load.

…82-reimpl

…r effect

reactive.flush() awaited through a child task of a running flush or effect
(`asyncio.gather()`, or `asyncio.wait_for()` before Python 3.12) waited for
work that couldn't finish until that ancestor did, e.g. a flush pass that
can't start while the current flush is in a flushed callback, or an
effect's queued re-run. It now returns right away whenever the owning
flush or effect run is still going. A task whose starting effect has
finished (an extended task's body) still waits as usual.

A calc invalidated mid-run can be re-run by the next reader while the
stale run still awaits. If the stale run finished last it overwrote the
fresh value, and the calc then served it from the cache. Now only the most
recent run, if it wasn't invalidated, stores its result and ends the
running state; a superseded run returns its result to its own caller only.

A finished message handler no longer requests a flush (its ui.update_*() calls already do, via send_input_message()), and the latest calc run no longer skips caching when invalidated (_invalidated already forces the next read to recompute). Found by mutation testing: reverting either changed no observable behavior.

Mutation-tested all 34 fixes (revert one, run the suite): these tests
cover the ones that were only covered jointly or not at all -- the two busy
gates in _flush, the _start_cycle busy guard, the latest-run calc
bookkeeping, the idle transition ending the cycle, on_flush registration
requesting a flush, busy ending when a run is cancelled, no concurrent
flushes, the fresh flush context, and slow message handlers. The recording
connection also asserts that no output message is sent while busy.

From within an effect, or a task started by one that is still running, it returns right away. Previously this was only in the internal flush_settled() docstring.

After a reactive flush, the app used to await each requesting session's
_flush(), including its websocket send and on_flush callbacks, one after
another inside the global flush. A slow client or callback in one session
delayed every other session's output, the next reactive flush, and anyone
awaiting reactive.flush().

Each session now flushes in its own task, one at a time per session (a
request made mid-send runs once more afterwards, so messages stay in
order). An error closes that session only. reactive.flush() still waits
for these tasks, so its "settled" meaning is unchanged. A flush callback
that awaits reactive.flush() returns right away rather than waiting on its
own session's task.

Also skip the send when no cycle has ended and nothing is queued (R's
hasPendingUpdates()): each input update now yields one output message
instead of a value message plus an empty one.

request_flush() used get_running_loop(), so a value set from another
thread silently scheduled no flush, and calling loop.call_soon() from that
thread would not have been safe anyway. The environment now remembers the
loop Shiny runs on and hands requests from other threads (including a
thread running its own loop) to it with call_soon_threadsafe(); requests
are ignored if there is no loop yet or it has closed.

Only the request is thread-safe: Value.set()'s docs now say to call it on
the loop's thread, or via loop.call_soon_threadsafe(value.set, x).

Slow clients and slow on_flush callbacks delaying only their own session;
the next reactive flush not waiting on a stuck send; per-session sends
never overlapping and staying in order across cycles; reactive.flush()
waiting for pending sends; concurrent flush callbacks in two sessions;
a session closing mid-send with a re-run pending; a failed send closing
only its session; one output message per update. For threads: set() via
call_soon_threadsafe and direct, a thread with its own loop, merged
requests, no loop yet, a closed loop, and a new loop after the old one
closed. Every new code path was mutation-tested.

… B036)

… function

An error in `fn` closed the session with only the error message on stderr.
Now the traceback is printed first, as for an error in an effect. Also
document why `fn` must be synchronous.

`lock()` is usually called in a loop, so warning on every call floods the
console.

The span started with the current span as its parent, but it starts in
whichever task invalidated the session's effect, often another session's
effect or an earlier cycle of this one. One session's cycle then landed in
another session's trace. The first cycle's parent is now `session_start`
and later cycles start a trace of their own, as documented.

…dge cases

- A `reactive.calc` that reads itself cached the base case's value, because
  each nested run counted as a superseding one. Only the outermost run of a
  task writes the cache now.
- A `reactive.on_flushed()` callback that raised stopped the round-finished
  callbacks, including the app's output-flush hook, so the sessions' outputs
  were never sent. The error is printed and the other callbacks still run.
- The app's round-finished hook is unregistered when its last session ends,
  so an `App` no longer stays referenced by the reactive environment.

…ssion-end-cancel

# Conflicts:
#	tests/pytest/test_concurrency.py

…c-run-once-when-idle

# Conflicts:
#	tests/pytest/test_concurrency.py

…k-flush-replacement

# Conflicts:
#	shiny/reactive/_core.py
#	tests/pytest/test_concurrency.py

…-otel-session-span

…kmark-on-restore-order

…andler tasks

- Registering `session.on_flushed()` now requests an output flush, like
  `on_flush()` does, so a callback registered outside a cycle (from a message
  handler after an `await`, or a background task) runs; `ui.insert_ui()` from
  those places reaches the client.
- A flush requested from within the `on_flushed` callbacks is sent in one more
  message right after them, without running the callbacks again. Before, an
  `on_flushed(once=False)` callback that called `ui.update_*()` looped forever.
- Message-handler tasks are cancelled when the session ends, and an error
  escaping one (e.g. the response couldn't be sent) is printed and closes the
  session, instead of 'Task exception was never retrieved'.
- Note on `uploadEnd` that it sets its input mid-cycle, as Shiny for R does.

CHANGELOG: say 'round' where 'flush' meant one, list every early-return case
of `reactive.flush()`, note the new timing of `reactive.on_flushed()`, drop
the cross-thread `set()` endorsement and the #1785 input-handling claim, and
add entries for #1889/#21 and for uploads no longer marking the session busy.
Docstrings and the bundled skill use the same vocabulary.

…ssion-end-cancel

…c-run-once-when-idle

…k-flush-replacement

# Conflicts:
#	CHANGELOG.md
#	shiny/reactive/_core.py
#	tests/pytest/test_concurrency.py

…-otel-session-span

# Conflicts:
#	CHANGELOG.md

…kmark-on-restore-order

# Conflicts:
#	tests/pytest/test_concurrency.py

… reporting it